Как мы писали недавно, в новой версии платформы VMware vSphere 6, которая сейчас находится в стадии публичной беты, появились возможности использования томов VVols (о которых мы писали здесь). Сейчас эта функциональность также находится в бете и доступна для загрузки вот тут. 

Концепция VVol (она же VM Volumes) увеличивает уровень гранулярности работы хост-сервера с хранилищем за счет непосредственных операций с виртуальной машиной, минуя сущности "LUN->том VMFS->Datastore". Тома VVol является неким аналогом существующих сегодня LUN, но с меньшим уровнем гранулярности операций по сравнению с томами VMFS (последние, как правило, создаются из одного LUN). Таким образом, ВМ находится на одном VVol как всадник на лошади.

Чтобы виртуальные машины можно было создавать на томах VVols и производить с ними различные операции, нужно чтобы дисковый массив поддерживал такой интерфейс как vSphere APIs for Storage Awareness (VASA). Через этот API возможна передача функций, обычно выполняемых хостом ESXi, на сторону аппаратного хранилища. Кроме того, есть также интерфейс vSphere Storage API – Array Integration (VAAI), который также используется для offloading'а операций на сторону массива, особенно когда дело касается операций миграции и клонирования ВМ.

Давайте посмотрим, как эти два API (VASA и VAAI) работают с хранилищем при операциях клонирования виртуальных машин, которые часто нужны в инфраструктуре виртуальных ПК на базе VMware Horizon View.

Сценарий 1 - клонирование ВМ в рамках одного контейнера VVol

В этом случае через API VASA вызывается функция cloneVirtualVolume, которая полностью передает на сторону дискового массива операцию клонирования ВМ:

Сценарий 2 - клонирование ВМ в рамках разных VVol

В этом случае все зависит от того, на каких хранилищах находятся данные VVol. Если VVol-a и VVol-b находятся на двух массивах одного вендора, настроенных единообразно, и управляются одним VASA Provider, то в этом случае используется API VASA и вызывается функция cloneVirtualVolume.

Если же VVol-a и VVol-b находятся на одном массиве и настроены по-разному, либо хранилища VVol-a и VVol-b находятся на двух массивах разных вендоров или моделей, то операция через VASA API может не пройти. Тогда происходит переключение на VAAI API, который использует датамувер ESXi (vmkernel data mover) и примитивы VAAI для клонирования виртуальной машины. При этом в случае неудачи передачи операций клонирования на сторону массива датамувер может начать перемещать данные через хост ESXi (подробнее - тут):

Конечно же, предпочтительнее делать все через VASA API - такая операция пройдет быстрее, поскольку в ней не будет задействован хост ESXi. Поэтому тут важна унификация конфигурации хранилищ и дисковых массивов в инфраструктуре. Ну и надо, конечно же, смотреть, чтобы закупаемые массивы в полной мере поддерживали VASA и VAAI.

Сценарий 3 - клонирование ВМ с тома VMFS на VVol

Если получается так, что ВМ надо склонировать с тома VMFS на хранилище VVol, то тут будет работать только операция XCOPY / WRITE_SAME интерфейса VAAI.

При этом работает это только для операции в направлении VMFS->VVol, при обратном клонировании этот API использован не будет.

Узнать больше о томах VVol и позадавать вопросы на эту тему вы можете на специальной странице Virtual Volumes beta community.

Недавно компания VMware выпустила интересное видео - vSphere Distributed Switch (vDS) Concept, из которого начинающие пользователи платформы виртуализации VMware vSphere могут понять, зачем именно им нужен распределенный виртуальный коммутатор:

Как показано в видео, VMware vDS нужен для следующих вещей:

• Централизация операций по управлению сетевой конфигурацией хостов VMware ESXi.
• Мониторинг состояния сетевых компонентов инфраструктуры на различных уровнях и решение проблем (траблшутинг).
• Резервное копирование и восстановление конфигурации сети в случае сбоев.
• Возможность приоретизации различных типов трафика (NetIOC).
• Расширенные возможности для сетевых администраторов.

Это видео неплохо бы показать своему сетевому администратору перед внедрением vDS, если вы его планируете. Кстати, для тех, кто хочет узнать больше о возможностях распределенных коммутаторов от VMware и Cisco, есть отличный документ на русском языке "Сетевые функциональные возможности распределенного виртуального коммутатора VMware vSphere и коммутаторов Cisco Nexus серии 1000V". Из таблички, приведенной в нем, видно, какие новые возможности появляются у коммутатора vDS по сравнению с ESXi Standard vSwitch:

На прошлой неделе появился ежегодный "магический квадрант" аналитической компании Gartner в области виртуализации серверной инфраструктуры - Magic Quandrant for x86 Server Virtualization Infrastructure 2014.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Посмотрим, как выглядели такие же магические квадранты в 2013 и 2014 годах:

Изменения, видимые на глаз:

• VMware чуть вырвалась вперед по отношению к Microsoft как "визионер" (благодаря таким решениям, как Virtual SAN и Horizon 6).
• Продукт Citrix XenServer заглох, а Citrix стала нишевым игроком.
• Компания Red Hat заметно прибавила, особенно как визионер.
• Появился новый игрок - Huawei с нишевым решением FusionSphere (ответвление Xen), которое будет продвигаться на развивающихся рынках, таких как Бразилия, Россия, Индия и Китай.

По поводу своего технологического превосходства компания VMware даже выпустила елейное видео:

В целом все логично и идет к нашему прогнозу 2016 года:

Интересен также такой факт в отчете Gartner, что 70% серверов архитектуры x86 (в среднем по миру) уже являются виртуальными. Кроме того, отмечается, что все больше крупных компаний используют сразу несколько гипервизоров в частных или публичных гибридных облаках. Больше подробностей о преимуществах и недостатках каждой из платформ виртуализации приведено в отчете Gartner.

Некоторое время назад мы писали про особенности и ограничения виртуального модуля VMware vCenter Server Appliance (vCSA) по сравнению с обычным серверов vCenter, устанавливаемым в ОС Windows физической и виртуальной машины. Также мы писали о том, что выбрать - установку vCenter в виртуальной машине или использование vCSA.

Недавно на блогах VMware появился интересный пост, по-сути говорящий о том, что модуль vCSA имеет несколько ограничений и неприятных аспектов эксплуатации, которые надо учитывать, и которые не позволяют использовать это решение в производственной среде.

Приведем здесь эти тезисы:

1. Из всех ограничений VMware vCenter Server Appliance самым основным является отсутствие средства обновления хост-серверов VMware ESXi - VMware Update Manager (VUM). Его конечно можно поставить на отдельную Windows-машину, но тогда весь смысл vCSA теряется. Эту ситуацию обещают исправить в VMware vSphere 6.0. Кроме того, отсутствие таких функций, как Linked Mode, работы с кластерами VSAN и поддержки внешней БД Microsoft SQL Server делают для многих модуль vCSA неприемлемым.

2. Лимиты vCSA (100 хостов и 3000 машин) меньше таковых у vCenter Server (1000 хостов и 10 000 виртуальных машин). Это, конечно, актуально только для больших компаний, но все же. Если понадобится, то с vCSA можно использовать внешнюю БД, но только Oracle.

3. В качестве гостевой ОС для vCSA используется дистрибутив SUSE, который имеет отдельную от VMware политику обновлений. VMware не накатывает эти обновления и хотфиксы, как только они становятся доступны. Соответственно, этот факт может вступить в конфликт с политикой информационной безопасности, предполагающей своевременное обновление компонентов виртуальной инфраструктуры.

4. Использование модуля vCSA по-прежнему предполагает знание внутренностей Linux. Если с vCenter Server for Windows справится любой администратор, то для vCSA потребуется квалифицированный специалист, если там что-то сломается.

5. Если в силу перечисленных ограничений вы решите смигрировать с vCSA на vCenter для Windows, это может оказаться проблематичным, так как никаких средств миграции не предусмотрено. Это придется делать вручную, а между тем политика во многих организациях требует сохранения исторических данных (о производительности, действиях администраторов и прочего). Сохранить эти данные не получится.

Поэтому, все-таки, VMware vCenter Server Appliance пока еще не готов для производственной среды, однако мы ожидаем, что ситуация с выходом vSphere 6.0 значительно улучшится.

Не так давно мы писали про виртуальный модуль vSphere OpenStack Virtual Appliance (VOVA), позволяющий построить архитектуру OpenStack на базе платформы виртуализации VMware vSphere. Теперь компания VMware решила пойти дальше и продемонстрировать пример того, как можно построить облачную IaaS-инфраструктуру на базе хранилищ Virtual SAN и решения для агрегации и виртуализации сетей VMware NSX, обеспечивая при этом прозрачную коммуникацию между виртуальными машинами (инстансами), исполняемыми на VMware vSphere и гипервизоре KVM.

В данной демонстрации используется Cloud Management Portal в рамках архитектуры OpenStack, позволяющий управлять сетевым взаимодействием multitenant-инфраструктуры. Для демо используется реальная инфраструктура, насчитывающая 200 инстансов, работающих на VMware ESXi и KVM. В качестве бэкэнд-хранилищ выступают датасторы VMware VSAN.

В процессе демонстрации показывают следующие вещи:

• Создание виртуальных сегментов сетей датацентра (публичная веб-сеть и сеть приложений)
• Создание виртуального роутера для маршрутизации между виртуальными сетями.
• Назначение виртуальных сетей инстансам (виртуальным машинам) и демонстрация работоспособности заданных правил сетевого взаимодействия.
• Приведение инфраструктуры в изначальный вид - удаление инстансов, виртуального роутера и виртуальных сетей.

Интересны следующие особенности показанной архитектуры:

• Коммуникация между виртуальными машинами на разных гипервизорах и в разных виртуальных сетях идет на уровне L2 через оверлей, при этом модификация существующей физической сети не требуется.
• Между тенантами (организациями в IaaS-инфраструктуре) существует полная логическая изоляция, то есть можно создавать для них роутеры и виртуальные сети, используя одну физическую подсеть, при этом организации будут надежно разделены.
• На виртуальном роутере используется NAT на уровне тенанта, который позволяет использовать любую схему IP-адресации, а также плавающие (floating) IP для инстансов внутри тенанта, не нарушая работу инфраструктуры в целом.
• Возможности безопасности в NSX, реализуемые в рамках OpenStack-архитектуры позволяют управлять и ограничивать входящий и исходящий трафик между виртуальными сетями, а также между инстансами в одной сети.
• Virtual SAN как бэкэнд-хранилище предоставляет ресурсы для томов Cinder Volumes, которые являются основным контейнером для хранения инстансов.
• Создание виртуальных сетей, маршрутизации между ними в multitenant IaaS-инфраструктуре показывает как сильно решение NSX упрощает жизнь - за несколько минут были созданы виртуальные сети и настроена маршрутизация между ними для коммуникации инстансов, а потом так же быстро удалили все созданные сущности - и все это без модификации настроек коммутаторов, маршрутизаторов и прочих компонентов физической сети.

Как вы все знаете, недавно компания VMware объявила о доступности для загрузки своего флагманского решения для управления инфраструктурой виртуальных и физических ПК VMware Horizon 6, основной частью которого является компонент для создания VDI-среды VMware Horizon View (также недавно мы писали про решение VMware Workspace).

Вместе с основными составляющими решения Horizon были обновлены также клиенты Horizon View Clients, которые теперь поддерживают возможности View Hosted Apps - то есть организацию доступа к приложениям на серверах Windows Remote Desktop Session host (RDS) по протоколу PCoIP. Работает этот механизм аналогично решению Citrix XenApp - с различных устройств (ПК, планшет, телефон) пользователь получает бесшовное окно своего приложения в основной рабочей среде, при этом передается только картинка этого окна, а само приложение исполняется на сервере RDS.

Это выглядит так, будто бы приложение исполняется локально. Вот так, например, это выглядит на Маке, где иконки Windows-приложений помещаются в док-панель:

Технология VMware View Hosted applications поддерживается не только на ПК, но и на устройствах iOS и Android. Например, вот картинка приложения Adobe Reader с экрана телефона на Android:

Последнее обновление клиентов было в январе 2014 года (когда их версия была 2.3), а с выпуском новой версии Horizon 6 их версия продвинулась до 3.0. При этом клиенты Windows Store и HTML Access web client получили версию 2.4, а Linux-клиенты не обновлялись. Не путайте клиент для Windows Store с клиентом для Windows - последний имеет версию 3.0.

Таким образом, функциональность клиентов VMware Horizon Clients распределена по версиям следующим образом:

• Horizon Client 2.3 - клиенты, выпущенные в январе 2014 без поддержки Hosted Apps.
• Horizon Client 2.x - клиенты более новой версии, но без поддержки Hosted Apps.
• Horizon Client 3.0 - клиенты с поддержкой Hosted Apps.

Если клиент не поддерживает функциональность Hosted Apps, то эти приложения просто не будут видны в интерфейсе. Кстати, Hosted Apps для Mac OS поддерживаются, начиная с версии OS X 10.8.

Интересно также, что для устройств iPad и iPhone поддерживается аутентификация через смарт-карты от Biometrics Associates (поддерживаются такие типы устройств, как CAC, PIV и Gemalto):

Кроме всего прочего, клиенты View Horizon Clients получили унифицированный дизайн и интерфейс на всех платформах, что ускоряет адаптацию решения пользователями:

Скачать все клиенты VMware Horizon Clients можно по одной ссылке: http://www.vmware.com/go/viewclients.

Документация по клиентам Horizon доступна тут.

Недавно мы писали про выпущенные в мае технологические превью новых версий настольных платформ виртуализации VMware Workstation и VMware Fusion, а на днях компания VMware обновила функциональность этих продуктов, выпустив VMware Workstation 11 и VMware Fusion 7 Technology Preview July 2014. Больше всего новых возможностей в этом выпуске получила платформа Fusion 7.

Июльский VMware Workstation 11 TP обладает следующими новыми возможностями:

• New OS Support - Теперь появилась поддержка не только Windows 8 / 8.1, но и Windows 8.1 Update 1 в качестве хостовой и гостевой ОС. Кроме того, поддерживаются также последние версии десктопных платформ Ubuntu, Fedora, RHEL, OpenSUSE и других Linux-дистрибутивов. К моменту релиза список будет уточнен.
• VMware Hardware Version 11 - очередное обновление поколения виртуального программного обеспечения. Теперь возможностей у устройств виртуальной машины станет значительно больше. Например, можно создавать виртуальные машины с числом виртуальных процессоров (vCPU) до 16, кроме того улучшилась поддержка устройств USB 3.0, и появилась возможность выделять графическую память на уровне отдельной гостевой ОС.
• CPU enablement - кроме поддержки 16 vCPU, появилась полная поддержка новых поколений процессоров микроархитектур Intel Haswell и AMD Jaguar. Также поддерживаются на уровне совместимости процессоры Intel Broadwell и AMD Steamroller.
• Virtual xHCI controller - виртуальный контроллер xHCI появился еще в версии virtual hardware 8, но в этой версии он соответствует спецификации Intel xHCI 1.0. Также тут ожидается лучшая производительность устройств USB 3.0.
• Dedicated graphics memory for guest operating system - теперь полностью доступно управление выделением графической памяти под гостевые ОС. Это дает пользователю больший контроль и гибкость в конфигурации виртуальной машины. Настройка эта регулируется в Virtual Machine Settings -> Hardware -> Display. Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
• Windows 8 Unity mode improvements - был существенно улучшен процесс работы с механизмом Unity, особенно для ВМ под управлением Windows 8 / 8.1. Кроме того улучшилась работа с экраном "Пуск" - когда происходит переключение между гостевой и хостовой ОС.
• Boot virtual machine with EFI - эта версия Workstation позволяет создавать и запускать виртуальную машину на базе EFI как альтернативе BIOS. Для этого нужно выставить следующую настройку - Virtual Machine Settings -> Options -> Advanced, далее отметить "Boot with EFI instead of BIOS".
• [новое] Experimental performance tuning for VM suspend and resume - в этом релизе платформы можно улучшить производительность операций по приостановке и возобновлению работы виртуальной машины (suspend/resume). Для этого машина должна иметь версию виртуального аппаратного обеспечения (Hardware Version) 11. Для этого необходимо в vmx-файл конфигурации ВМ добавить следующие строчки:
  mainMem.save.vmem="FALSE"
checkpoint.compressDumper="TRUE"
  Этот твиг действует как для шифрованной, так и обычной виртуальной машины. Он ускоряет suspend до 20% и resume до 60%.

Больше подробностей о возможностях VMware Workstation 11 рассказано на этой странице. Скачать превью решения можно по этой ссылке.

Июльский VMware Fusion 7 TP получил вот такие новые возможности:

• Новое поколение виртуального программного обеспечения - Hardware Version 11. (VM > Settings > Compatibility). Описание см. выше.
• Новые иконки в библиотеке, которые показывают состояние виртуальной машины в представлении списком.
• Поддержка настройки видеопамяти для гостевой ОС (VM > Settings > Display). Описание см. выше.
• Настройка использования встроенной видеокарты для Mac Book Pro с более, чем одним графическим модулем (GPU).
• Обновленная поддержка конфигураций с несколькими мониторами, один из которых Retina.
• Возможность настраивать горячие клавиши отдельно для каждой ВМ (VM > Settings > Keyboard & Mouse).
• Улучшенная поддержка предрелизных версий Microsoft Windows.
• Новый упрощенный способ установки VMware Tools под Windows 8 с использованием виртуального устройства USB CD virtual device.
• [новое] Поддержка просмотра хостов VMware Workstation, VMware ESXi, VMware vSphere в библиотеке (в меню нужно выбрать File > Connect to Server).
• [новое] Возможность удаленного управления виртуальными машинами на платформах VMware Workstation, VMware ESXi и VMware vSphere.
• [новое] Улучшенная поддержка для еще не вышедших версий Mac OS X.
• [новое] Возможность расшарить камеру iSight между хостовой и гостевой ОС.

Больше подробностей о возможностях VMware Fusion 7 рассказано на этой странице. Скачать превью решения можно по этой ссылке.

Те из вас, кто интересуется VDI-инфраструктурой, знают про калькулятор VDI Calculator (последний раз мы писали о нем тут), который разрабатывает Andre Leibovici, автор сайта myvirtualcloud.net. Сегодня это калькулятор номер 1 для расчета параметров инфраструктуры виртуальных ПК на базе VMware View и Citrix XenDesktop - он позволит ответить на такие вопросы как: сколько серверов нужно для построения инфраструктуры виртуальных ПК, какие у них должны быть аппаратные характеристики, сколько дисковых емкостей нужно для размещения ВМ и т.п.

На днях Андрэ выпустил шестую версию своего калькулятора, в которой появилось несколько интересных новых возможностей.

Итак, новые возможности VDI Calculator v6.0:

• Horizon View and XenDesktop Infrastructure Calculation - если раньше калькулятор просто рассчитывал необходимое количество серверов View Connection и Security, либо XenDesktop Controller, то теперь он позволяет конкретно получить информацию о том, сколько вычислительных ресурсов потребуется для размещения управляющих компонентов инфраструктуры. Для этого нужно выбрать опцию "Backend Infrastructure".
• Java Code Signing - теперь код продукта подписан и не вызывает консёрна пользователей при его запуске.
• Write Cache Sizing - когда вы используете опцию сайзинга для десктопов типа Horizon View Linked Clones или XenDesktop MCS, то калькулятор определяет размер дельты и кэша. Можно указать свои значения, если у вас есть собственная методика их расчета. Это позволит получить более корректные данные по целевой инфраструктуре.
• Поддержка узлов Nutanix NX-1050.
• Мелкие исправления ошибок

Калькулятор доступен по этой ссылке.

Как многие из вас знают, бета-версии платформы виртуализации VMware vSphere всегда были закрытыми, тестировал их очень ограниченный круг пользователей, находившихся под действием соглашения NDA (Non-disclosure agreement), которое подразумевало страшные кары и звонки юристов в случае его нарушения. В письмах с новостями о бета-версии были большие красные буквы про конфиденциальность, а за разглашение информации о новых возможностях продукта пытались наказать всех подряд, даже тех, кто этого соглашения не подписывал.

Возможно, компании VMware надоела вся эта канитель, и она впервые в своей истории решилась на открытое бета-тестирование VMware vSphere 6.0, но (видимо, по привычке) решила запретить публичное разглашение и обсуждение сведений о новой версии продукта.

For the first time, and unlike previous beta cycles for vSphere, this vSphere Beta is open to everyone to sign up and allows participants to help define the direction of the world’s most widely adopted, trusted, and robust virtualization platform.

Зарегистрировавшись в публичной бета-программе и подписав NDA, пользователи попадают в закрытое общество, где они могут обсуждать новые возможности платформы VMware vSphere, но им как бы запрещено это обсуждать с теми, кто не принимает участие в бете. Звучит как что-то очень параноидальное, но это так.

Итак, как участник VMware vSphere Beta Program вы можете:

• Обсуждать продукт и саму программу с другими участниками бета-программы.
• Постить в закрытые форумы на VMware Communities.
• Общаться с вендорами серверного оборудования на эту тему (они тоже должны быть под NDA).

В то же время как участник VMware vSphere Beta Program вы не можете:

• Обсуждать условия программы или новые возможности продукта публично.
• Обсуждать программу приватно, но с теми людьми, которые не находятся под NDA.

В общем, можете сами теперь попробовать, что такое VMware vSphere 6.0 Beta 2. Нужно нажать кнопку "Join now!" в правой части, после чего принять VMware Master Software Beta Test Agreement (MSBTA) и vSphere Program Rules agreement. Бесспорно, публичная бета-кампания позволит VMware поднять качество своих продуктов, так как любой желающий сможет сообщить об ошибке, возникшей у него в тестовой среде.

Одновременно с анонсом публичной беты VMware vSphere 6.0 компания VMware раскрыла некоторые подробности о функциональности Virtual Volumes (VVols), о которой мы писали вот тут. Концепция VVol (она же VM Volumes) увеличивает уровень гранулярности работы хост-сервера с хранилищем за счет непосредственных операций с виртуальной машиной, минуя сущности "LUN->том VMFS->Datastore". Тома VVol является неким аналогом существующих сегодня LUN, но с меньшим уровнем гранулярности операций по сравнению с томами VMFS (последние, как правило, создаются из одного LUN).

То есть, VVol - это низкоуровневое хранилище одной виртуальной машины, с которым будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Делается это через механизм vSphere APIs for Storage Awareness (VASA). Таким образом, все необходимое хранилище виртуальной машины упаковывается в этот самый VVol. Более подробно о томах VVol можно узнать на специальной странице.

Само собой, такое должно поддерживаться со стороны производителей хранилищ, которые уже давно работают с VVol и записали несколько демок:

Tintri

SolidFire

HP 

NetApp

EMC

Nimble Storage

Ну а вообще, конечно, это шаг вперед по сравнению с той паранойей VMware, которая была раньше вокруг бета-версий VMware vSphere.

Как многие из вас знают, пару недель назад компания VMware сделала доступным для загрузки решение VMware Horizon 6, содержащее в себе набор продуктов для управления инфраструктурой виртуальных и физических ПК предприятия.

Одним из таких продуктов является решение VMware Workspace Portal 2.0, которое раньше было известно как VMware Horizon Workspace. Оно позволяет предоставить пользователю унифицированное рабочее пространство для запуска различных приложений и других объектов, таких как SaaS-сервисы, виртуальные ПК VMware Horizon View и прочее с применением таких технологий как Blast, Single Sign-On и т.п. То есть это средство федерации ИТ-сервисов:

В этой версии продукта компания VMware убрала функции Horizon Files (которые еще были в версии 1.8), предоставила возможность запускать приложения View Hosted Apps и Citrix XenApp (аналоги возможностей по доставке приложений в бесшовных окнах от VMware и Citrix), а также сделала еще несколько важных изменений, чтобы продукт вписывался в линейку Horizon 6.

Новые возможности VMware Workspace Portal 2.0:

• Поддержка решения VMware Horizon 6 и механизма View Hosted Applications (должен быть установлен View Horizon 6 и Horizon Client версии 3.0 или выше).
• Поддержка приложений Citrix XenApp (начиная с версии 5.0). На базе фермы XenApp назначаются права доступа пользователей Workspace к этим приложениям. Citrix Receiver должен быть установлен на клиентской машине.
• Workspace лишился следующих компонентов, которые были убраны за невостребованностью:
• Horizon Files (для тех, кто этим пользовался, есть вот такая статья)
• Horizon Switch device management
• Поддержка Office 365 и механизма аутентификации non-SAML - единый вход (SSO) используется для веб-приложений Office 365, Sharepoint и Outlook 365.
• Поддержка нескольких экземпляров "View pod" для одного пространства Active Directory.
• Поддержка приложений ThinApp 5.0 64-bit теперь нативная для Windows-агента (работает без дополнительного ПО). Доставка приложений теперь возможна на любой Windows-ПК даже не в домене - логин в систему идет через Kerberos.
• Поддержка ThinApp 5.0.1
• Улучшенный механизм работы с логами за счет механизма Elasticsearch.
• Улучшенная отчетность по активности пользователей и использованию ими приложений.
• Больше возможностей для брендинга стартовой страницы и управляющих элементов.
• Улучшенный механизм назначения прав, кроме того быстрее работает синхронизация со службами каталога.
• Поддержка нескольких DNS-серверов для компонента Workspace vApp.
• Обновление OPENSSL до версии openssl-1.0.1h, VMware Workspace де была зафикшена уязвимость Heartbleed и другие ошибки.
• Улучшенные средства управления и категоризация объектов.

Более подробно о новых возможностях VMware Workspace 2.0 можно узнать в Release Notes. Скачать продукт можно по этой ссылке в составе VMware Horizon 6 (пробная версия - тут).

Как многие из вас знают, в платформе виртуализации VMware vSphere есть множество удобных средств работы с хранилищами, включая средства позволяющие расширить том VMFS прямо из GUI клиента vSphere Client - достаточно лишь сделать Rescan HBA-адаптеров. Однако если необходимо расширить локальный том (Local VMFS), то тут встроенных средств уже нет, и все нужно аккуратно делать самому, как это описано в KB 2002461. Приведем здесь этот процесс, проиллюстрировав его скриншотами.

Недавно компания VMware выпустила интересный документ "VMware Virtual SAN Ready Nodes", в котором приведены примеры серверных конфигураций от различных производителей, которые подходят в качестве узлов отказоустойчивого кластера хранилищ VMware Virtual SAN.

В обновленной версии документа были удалены некоторые старые конфигурации серверов, а новые добавлены. В ближайшие несколько недель ожидается пополнение документа новыми моделями и конфигурациями узлов.

К каждой спецификации на сервер прилагается профиль нагрузки, для которой предлагается его использовать, например, VDI-инфраструктура с числом виртуальных ПК до 100 или серверная инфраструктура на 60 ВМ. Также прилагается примерная конфигурация виртуальной машины, например:

Virtual Machine Profle: 2 vCPU, 6 GB Memory, 2 x 60 GB virtual disks

Пока в документе есть серверы только четырех производителей (но скоро точно будет больше):

• Dell
• Fujitsu
• HP
• SuperMicro

Также у компании VMware на тему выбора и сайзинга кластеров Virtua SAN есть полезный документ "Virtual SAN Hardware Quick Reference Guide", где рассматриваются различные профили нагрузок виртуальных машин, размещенных на хранилищах отказоустойчивого кластера VSAN.

В первой таблице документа в столбцах приведены примеры нагрузок (например, полные клоны виртуальных десктопов или средняя серверная нагрузка), а в строчках рассматриваются различные аппаратные характеристики узлов, такие как вычислительные мощности, число дисков и их емкость, память, сетевые адаптеры и т.п.:

Также в документе есть рекомендации по сайзингу кластера хранилищ, а также рекомендуемым аппаратным характеристикам (например, число дисковых групп или необходимая минимальная глубина очереди на дисковом контроллере).

Напомним также, что есть еще документ "VMware Virtual SAN Hardware Design Guide", который может вам помочь с выбором узлов для кластера Virtual SAN.

Бывает такое, что пользователь системы жалуется администратору виртуальной инфраструктуры VMware vSphere, что у него пропал сетевой адаптер в виртуальной машине, и она больше недоступна из внешней сети. Администратор смотрит в лог виртуальной машины (vmware-##.log) и видит там вот такое:

Mar 15 03:13:37.463: vmx| Powering off Ethernet1 
Mar 15 03:13:37.463: vmx| Hot removal done.

Это, как вы уже догадались, означает, что кто-то тыкнул на иконку "Safely Remove Hardware" в гостевой ОС и выбрал там сетевой адаптер ВМ:

Либо это было сделано случайно в vSphere Client или Web Client. Поправить это легко - надо отключить функции Hot Add для виртуальной машины.

Для этого:

• Соединяемся с хостом ESXi/ESX напрямую или через vCenter Server посредством vSphere Client.
• Выключаем виртуальную машину.
• Выбираем для нее Edit Settings и переходим на вкладку Options.
• Выбираем General > Configuration Parameters > Add Row.
• Добавляем строчку с именем devices.hotplug и значением false.
• Включаем виртуальную машину.

После этого при попытке удаления устройства работающей виртуальной машины будет выдано такое сообщение

Если же вы не хотите запрещать Hot Add для всех устройств, а хотите просто спрятать возможность удаления сетевой карты из Safely Remove Hardware, то нужно сделать следующее:

• Запустить редактор реестра как Local System. Для этого можно использовать утилиту psexec Tool.
• Выполняем psexec -i -s regedit.exe.
• Идем в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum ищем наш драйвер NIC (в его названии есть VMXNET3, E1000 и т.п.).
• Установите значение ключа Capabilities на 4 единицы ниже.

Например, вот тут мы видим значение ключа 16:

Устанавливаем его на 4 меньше, то есть в значение 12:

После этого сетевой адаптер исчезнет из безопасного удаления устройств:

Некоторое время назад мы писали о том, что в самом ближайшем будущем ожидается выпуск обновленной версии решения для управления виртуальными и физическими ПК предприятия VMware Horizon 6. В преддверии выпуска этого продукта компания VMware запустила виртуальную лабораторную работу HOL-MBL-1451 - Horizon 6 with View Introduction, посвященную работе с решением для виртуализации ПК VMware Horizon View:

Лабораторные работы VMware Hands-On Labs (HOL) - это один из лучших форматов знакомства с продуктами VMware, так как в процессе их выполнения вы видите их интерфейс с пояснениями о назначении различных возможностей, а также указания, касающиеся дальнейших действий администратора. То есть самостоятельно нужно тыкать на клавиши и делать различные настройки, что гораздо лучше презентаций и мануалов.

За 4 часа, выделенных на лабораторную работу, администратор VMware View пройдет через процесс установки и настройки VDI-инфраструктуры и узнает обо всех новых возможностях продукта, включая такие функции как Application Remoting и архитектура Cloud Pod.

Если вы не хотите проходить лабу, а просто хотите ознакомиться с ее описанием в текстовом формате с картинками, то вот, пожалуйста:

• HTML - http://docs.hol.vmware.com/HOL-2014-staging/hol-mbl-1451-spr_html_en/
• PDF –  http://docs.hol.vmware.com/HOL-2014-staging/hol-mbl-1451-spr_pdf_en.pdf

Также вот тут можно обсудить данную лабораторную работу и пообщаться на тему VMware Horizon View 6.

Не так давно мы писали о том, что была выпущена новая версия решения VMware Log Insight 2.0, предназначенного для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. На днях компания VMware выпустила для него Windows Content Pack, который позволяет получать информацию о состоянии Windows-систем и их приложений.

Данный контент-пак покрывает множество аспектов работы Windows-систем, которые представлены в категориях General, System, Application и Security. Представления включают в себя 10 групп дэшбордов, 52 виджета, 6 алертов и 41 получаемое поле данных.

Скачать Windows Content Pack для VMware Log Insight можно по этой ссылке.

Как вы знаете, в VMware vSphere (еще с версии 5.1) есть механизм репликации виртуальных машин vSphere Replication (VR), который позволяет создавать копию виртуальной машины на другом хосте и хранилище на случай сбоя. Именно она используется для асинхронной репликации в катастрофоустойчивом решении VMware vCenter Site Recovery Manager (SRM).

Периодичность репликации со стороны владельца системы должна задаваться политикой RPO (Recovery Point Objective), определяющей какое максимальное количество данных выраженное во времени мы можем потерять в случае сбоя. Например, RPO=15 минут означает, что самое большое, что не будет подлежать восстановлению - это изменения, произошедшие в системе за последние 15 минут.

Этот параметр и задается в первую очередь при настройке репликации для виртуальной машины:

Здесь можно задать значение от 15 минут до 24 часов. Однако не обязательно это требование будет выполнено, ведь если ширина канала у вас небольшая, а машин на хостах много, то они просто могут не поместиться в эту полосу с необходимой для обеспечения RPO частотой репликации.

Кстати, на данный момент расписание задачи репликации генерируется автоматически на основании исторических данных об изменении блоков виртуальных дисков за последние 48 часов. При этом расписание репликации пересчитывается каждый раз, когда виртуальная машина меняет свое состояние (питание, реконфигурация репликации и т.п.).

Поскольку задаче репликации нужно некоторое время на выполнение, каждая реплика считается устаревшей к тому времени, как сама задача считается выполненной. Поэтому чтобы предотвратить нарушение политики RPO, vSphere Replication должна выполнить задачу репликации за половину времени, определенного политикой RPO. Половину - так как если вторая репликация не сможет завершиться в случае сбоя, то мы сможем вернуться только в то состояние виртуальной машины, которое предшествовало началу первой репликации. Для этого потребуется восстановить первую реплику.

Ожидаемое время репликации вычисляется как среднее время последних 15 репликаций плюс 20% прибавка в качестве запаса к этому времени.

Рассмотрим пример:

Здесь у нас установлено RPO=60 минут. В первом случае на репликацию ушло 22 (текущая) и 23 (ожидаемая) минуты, каждая из них меньше половины времени RPO, соответственно политика считается выполненной. Во втором случае текущая и следующая репликации выходят за границы половины RPO, обе репликации в сумме дают 68 минут, поэтому политика считается нарушенной.

То есть, если исходный хост навернется через 67 минут, то мы сможем откатиться только в то состояние хоста, которое было 67 минут назад (восстановив первую реплику), что противоречит политике RPO, которая была определена как 60 минут.

В случае нарушения RPO сама репликация будет продолжена, однако вы будете получать вот такие алерты в консоли vSphere Client:

Что в этом случае делать? Выхода всего два - либо увеличивать и согласовывать новое RPO для сервиса виртуальной машины, либо увеличивать доступную полосу пропускания для сети репликации, что должно уменьшить время выполнения задачи.

Кстати, в плане определения необходимой ширины канала для репликации вам поможет специальное средство VMware vSphere Replication Capacity Planning Appliance.

В последнее время компания VMware активно перепаковывает свои продукты и пересматривает целесообразность их существования. Недавно было объявлено о снятии с производства решения для защиты сервисов управляющего компонента виртуальной инфраструктуры - VMware vCenter Server Heartbeat:

В марте было объявлено о снятии с продаж продукта VMware Storage Appliance (VSA), который стал недоступен к заказу с 1 апреля этого года:

На смену ему пришел продукт нового поколения VMware Virtual SAN, про который мы уже очень много писали на страницах нашего сайта (см. поиск по тэгу VSAN).

Теперь пришел черед продукта для биллинга использования ресурсов виртуальной инфраструктуры VMware vCenter Chargeback Manager, о котором мы уже писали вот тут. Он стал недоступен для заказа с 10 июня этого года (поддержка будет оказываться еще год):

Возможности биллинга виртуальной инфраструктуры уже некоторое время назад были перемещены в модуль IT Business Management (ITBM), который позволяет считать затраты в частном облаке VMware vSphere и vCloud Director:

Этот модуль интегрирован с продуктом vCloud Automation Center 6.0 (vCAC), предназначенным для управления облачной инфраструктурой предприятия (SaaS, PaaS, IaaS) средствами единого решения, построенного поверх VMware vCloud Director (для IaaS-инфраструктуры) и разработанного на базе решения DynamicOps (бывший продукт Virtual Resource Manager, VRM). О нем мы уже писали вот тут.

Функции биллинга и финансовой отчетности уже есть в блоке IT Financial Management продукта ITBM. Так например видит затраты на инфраструктуру VMware ИТ-директор предприятия:

Сам продукт IT Business Management Suite поставляется в трех изданиях, функции финансовой отчетности и планирования есть в двух их них:

Напомним, что жизненный цикл доступности продуктов VMware и сроки их поддержки регулируются документом VMware Lifecycle Product Matrix.

На прошедшей неделе компания VMware вплотную занялась патчингом и фиксингом своих продуктов, закрывая те проблемные места, которые накопились за прошедшие пару-тройку месяцев. Прежде всего, было выпущено обновление ESXi550-201406401-SG, которое решает сразу две проблемы на VMware vSphere 5.5 Update 1.

Во-первых, мы уже писали о том, что  в VMware vSphere 5.5 Update 1 был баг - если использовать NFS-хранилища, то они периодически отваливаются, переходя в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

В выпущенном обновлении эта ошибка была исправлена.

Во-вторых, была также исправлена ошибка безопасности в OpenSSL, которая может оказаться даже серьезнее, чем исправленный ранее баг OpenSSL Heartbleed. В ESXi существует вероятность атаки типа MiM (Man in the Middle), о которой подробнее рассказано вот тут. Этот баг в приведенном выше обновлении был также зафикшен. Кстати, в своем блоге компания VMware объявила о том, что ее команда безопасности расследует новые возможные уязвимости OpenSSL, и вот тут приведены результаты ее работы.

Чтобы скачать патч, идем на VMware Patch Portal, выбираем там продукт "ESXi Embedded & Installable", версию релиза 5.5.0 и дату - 10 июня. Получаем ссылку на патч:

Применить этот патч можно и не скачивая его с сайта VMware, а просто с помощью следующей последовательности команд:

# открываем фаервол для http

esxcli network firewall ruleset set -e true -r httpClient

# устанавливаем образ ESXi-5.5.0-20140604001-standard из хранилища VMware Online depot

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20140604001-standard

# перезагружаем хост ESXi

reboot

Также на днях компания VMware выпустила обновления продукта vCenter Server 5.5 Update 1b:

и vCloud Director 5.5.1.2:

Оба этих исправления прежде всего несут в себе фиксы в плане безопасности протокола OpenSSL, однако там есть и другие мелкие улучшения. Рекомендуется их установить.

Надо отметить, что VMware vCenter Server Appliance не подвержен багу OpenSSL, поэтому и исправлений для него нет.

Не так давно мы писали о том, что в скором времени выйдет обновленная версия решения для управления физическими и виртуальными ПК предприятия VMware Horizon 6. В преддверии выпуска этого решения компания VMware выпустила интересный документ "Reviewer’s Guide for View in Horizon 6" (по-сути, это Evaluator's Guide), в котором рассматривается пошаговая установка и развертывание решения.

Основное назначение документа - показать, как нужно развертывать продукт, описать его основные возможности и рассказать на практике о том, как решение VMware View Horizon 6 умеет обращаться с виртуальными десктопами. Примечательная особенность данного документа - множество скриншотов и диаграмм - позволит быстро понять, как именно работает решение.

Кроме того, в документе упомянут интересный компонент View Agent Direct-Connection plug-in - плагин, который позволяет подключаться к любому виртуальному ПК, минуя VMware View Connection Server.

Содержание основных разделов документа:

• Architecture and Components
• Hands-On Evaluation Exercises
• Remote Desktop Session Host Configuration
• Configure Group Policy Setting fro RDS Host Sessions
• Preparing Desktop Images for Linked-Clone Desktop Pool Deployment
• Preparing a Desktop Image for Full-Clone Desktop Pool Deployment
• Deploying View Desktops and Applications
• Entitling Users to View Desktops and Applications
• Connecting to View Desktops and Applications

В документе также можно найти ссылки на другую полезную документацию VMware касательно пакета продуктов Horizon.

Спустя полгода с момента выпуска прошлой версии основного руководства по обеспечению безопасности виртуальной инфраструктуры, компания VMware обновила версию этого документа до vSphere Hardening Guide 5.5 Update 1. Надо отметить, что руководство по безопасности вышло аж через 3 месяца после выпуска самой vSphere 5.5 Update 1, что как бы не очень хорошо, так как многие пользователи уже используют U1 в производственной среде, и руководство им пригодилось бы раньше. Ну да ладно, бывало нужно было ждать и дольше.

Доступен также лог изменений с момента прошлого документа:

В новой версии руководства есть следующие важные изменения:

• enable-VGA-Only-Mode - эта рекомендация должна быть применена для виртуальных серверов, которым не нужен графический режим (обычно он используется для VDI-инфраструктуры). То есть для веб-серверов, серверов Windows Core и т.п. нужно этот режим включить, чтобы уменьшить поверхность возможной атаки.
• disable-non-essential-3D-features - аналогично, отключаем 3D-графику для виртуальных машин, которым это не нужно.
• use-unique-roles - если у вас несколько сервисных аккаунтов, то им не нужно назначать одну роль на всех, а нужно создавать для каждого отдельную с необходимым набором привилегий для решения нужной задачи.
• change-sso-admin-password - это рекомендация сменить пароль для аккаунта administrator@vsphere.local, когда вы используете виртуальный модуль VMware vCSA (готовая ВМ с vCenter). Для обычного vCenter этот пароль просят сменить при установке. Удивительно, но этой рекомендации раньше не было.

Ну и кроме всего прочего, было пофикшены различные ошибки (например, значения в некоторых ячейках были обрезаны), а некоторые рекомендации переместились в другие категории.

На блогах, посвященных VMware vSphere, вышла интересная статья про то, как организовать именование и тэгирование объектов инфраструктуры виртуализации, чтобы в ней был порядок, и можно было бы просто найти нужную виртуальную машину, хранилище, сеть или другой объект. Попробуем здесь вкратце изложить основные моменты.

1. Стандарт именования объектов - ключ к порядку.

Здесь подход прост - виртуальные машины и прочие объекты должны именоваться согласно двум принципам:

• унифицированно (то есть по шаблону имени)
• чтобы было понятно, что там внутри находится

Как пример, для виртуальных машин можно использовать такую схему:

<назначение>_<тип окружения>_<порядковый номер>

Например:

EXCH_PROD_01

Датасторы можно именовать, например, так:

<датацентр>_<окружение>_<дисковый массив>_<порядковый номер>

Например:

SLC_STAGE_VPLEX_02

Для виртуальных сетей:

<имя>_<тип трафика>_<номер VLAN>

Например:

FIN_PCI_730

Ну и так далее. По аналогии назначаем шаблон именования и, собственно, имена для следующих объектов:

• Кластеры
• Шаблоны виртуальных машин
• Политики хранилищ
• Профили хостов
• И т.п.

Сделав это и применив к своей инфраструктуре, можно будет просто ориентироваться и находить нужные объекты, а также всегда помнить для чего они вообще нужны (частая проблема).

2. Переименование объектов, которые были созданы ранее.

Иногда политики именования объектов вводят уже после того, как в инфраструктуре полный бардак. Поэтому, зачастую, приходится переименовывать виртуальные машины. О том, как это делается, мы уже писали вот тут.

Если ваша лицензия позволяет делать Storage vMotion, то самый простой способ переименования - это:

• Переименовываем машину в VMware vSphere Web Client:

• Теперь видим, что между именем машины и именем папки на датасторе есть несоответствие:

• Делаем Storage vMotion машины на другое хранилище:

• После успешной миграции видим, что имя машины соответствует имени папки на хранилище (имя виртуального диска и остальных файлов в папке также станут корректными):

Кстати, есть специальный скрипт, который позволяет выявить все несоответствия между именами виртуальных машин и соответствующими папками на хранилищах.

3. Организация окружения с помощью тэгов.

Тэги позволяют ввести удобную категоризацию объектов виртуальной инфраструктуры по бизнес-критериям, что позволит ориентироваться в них с точки зрения понятных критериев (например, виртуальные машины какого-нибудь отдела), а также быстро находить то, что нужно.

Тэг назначается одному или нескольким объектам, после чего их можно искать в vSphere Web Client по этому тэгу.

Чтобы начать использовать тэги, переходим в соответствующий раздел в левом меню Web Client:

Создаем новую категорию, которая будет контейнером для тэгов. Выбираем сервер vCenter, имя категории, тип допустимых значений (один или несколько тэгов из категории на объект), а также типы объектов, которым можно назначать тэги из категории:

Теперь категория видна в представлении Tags > Category:

Далее создаем новый тэг, задав имя и привязав его к созданной категории:

Теперь этот тэг мы можем назначить указанным объектам, например, виртуальной машине:

Выбираем нужный тэг и назначаем его:

Теперь при наборе его в поиске он выскакивает как подсказка:

По тэгу мы сразу получаем доступ к нужным объектам в vSphere Web Client (например, все тестовые машины или все хранилища, используемые бухгалтерскими машинами):

Соблюдение этих простых правил позволит вам поддерживать чистоту и порядок в вашей виртуальной инфраструктуре.

Не так давно мы писали о грядущей новой версии продукта Veeam Backup and Replication v8, предназначенного для резервного копирования и репликации виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Напомним, что в восьмой версии продукта будет поддержка работы с массивами NetApp, а также было анонсировано средство для восстановления объектов каталога - Veeam Explorer for Active Directory.

Но пока новой версии нет, а администраторы VMware vSphere во всю уже начинают внедрять кластеры отказоустойчивости хранилищ VMware Virtual SAN. Специально для них компания Veeam уже сейчас выпустила обновление Veeam Backup & Replication 7.0 Patch 4, в котором технология VSAN полностью поддерживается (версия билда 7.0.0.871). Если раньше эти хранилища просто не показывались в списке объектов для резервного копирования, то теперь все они выводятся как датасторы:

Несмотря на то, что это всего лишь патч, в нем появилось множество новых возможностей:

• VMware Virtual SAN (VSAN) - в дополнение к базовой поддержке VSAN, которая есть и у других вендоров бэкапа, в решении Veeam учитывается специфика VSAN при работе механизма intelligent load-balancing. Это позволяет при резервном копировании использовать те прокси-сервера, которые будут выкачивать диски виртуальной машины, размещенные на том же хосте ESXi, что и прокси-сервер. Это позволяет максимально быстро проводить бэкап и не загружать дополнительно продуктивную сеть трафиком резервного копирования. Это очень полезная вещь, пример ее применения смотрите тут.
• Поддержка Microsoft SQL Server 2014 - теперь эта СУБД поддерживается не только как продакшен-нагрузка в резервируемой виртуальной машине, но и как бэкэнд база данных для сервера Veeam Backup and Replication, а также Enterprise Manager.
• License key auto update - теперь продукт будет автоматически обращаться к серверу лицензий Veeam, чтобы обновить ключи, если таковое необходимо. Это нововведение упрощает жизнь сервис-провайдерам, которые используют модель лицензирования на основе подписки (постоянно приходится продлять ключик).
• Backup Copy - максимальное число точек восстановления для задачи Backup Copy выросло до 999. Также эта задача поддерживает функцию "докачки" бэкапа при разрыве сетевого соединения.
• Hyper-V - добавлена поддержка нескольких Hardware VSS Providers, которые раньше не обнаруживались, а как следствие не могли использоваться при выполнении задачи РК. Также лучше стали создаваться снапшоты - теперь используется алгоритм ожидания окончания теневого копирования на томе вместо мгновенного завершения задачи.

По поводу поддержки VSAN есть интересный аспект работы при выборе прокси-серверов для резервного копирования. Если большая часть объектов хранилища машины размещена на одном хосте - то будет использоваться его бэкап-прокси, а вот если разница между объемом объектов менее 5% на двух хостах, то будут использованы оба прокси. Примеры:

• Host A = 70% хранения, Host B = 30 % , Host C = 0%, будет использован прокси только на Host A.
• Host A = 40% , Host B = 41% , Host C = 19%, будут использованы прокси на Host A и Host B одновременно.

Скачать обновление Veeam Backup & Replication 7.0 Patch 4 можно по этой ссылке.

На днях продукту номер 1 для запуска виртуальных машин на настольных ПК (да, да номер 1, так как VirtualBox по функциям курит в сторонке) исполнилось 15 лет. Многие тысячи разработчиков, тестировщиков, проектировщиков и других специалистов по всему миру используют VMware Workstation для решения своих задач (я, например, застал еще Workstation 5). По случаю пятнадцатилетия компания VMware объявила о дополнительной скидке на апгрейд на Workstation 10 с более ранних версий в размере 30%. Для апгрейда по акции подходят версии Workstation 8 и 9, а также, в течение ограниченного времени, Workstation 7.

Напомним, что на данный момент актуальной версией является VMware Workstation 10, а совсем недавно вышло технологическое превью Workstation 11, где как всегда будет масса новых возможностей.

Самое интересное - это посмотреть на боксшоты продукта и то, как изменялся их дизайн на протяжении этих 15 лет (кликабельно):

Кстати, версия боксшота 1999 субъективно выглядит симпатичнее, чем картинка 2013 года.

На днях компания VMware сделала неожиданное для некоторых своих клиентов заявление - продукт для защиты серверов VMware vCenter (на уровне различных его компонентов) VMware vCenter Server Heartbeat снят с производства со 2-го июня 2014 года и не будет больше доступен. То есть, для него уже наступил End of Availability (EoA).

На самом деле, этот продукт всегда был каким-то непонятным. Продавали его в довесок к VMware vSphere, а заказчик потом и не знал, что с ним делать - интерфейс корявый, установка сложная, полезность сомнительная. Достаточно просто посмотреть на окно версии vCenter Server Heartbeat 5.5:

По-видимому, не меня одного раздражал этот иконочный привет из девяностых, а развивать продукт было сложно - надо ведь поддерживать как обычный vCenter, так и его линуксового собрата в виде готовой виртуальной машины - VMware vCenter Server Appliance (а его поддержки в Heartbeat не было).

Таким образом, теперь остаются следующие способы защитить сервер управления vCenter от сбоев:

• Использовать виртуальную машину с vCenter Server и защищать ее средствами VMware HA (полностью поддерживается).
• Использовать последние версии vCenter Server Heartbeat (End of Live).
• Использовать кластер MSCS для сервера vCenter (не поддерживается).
• Использовать сторонние решения по кластеризации (не поддерживается).
• Использовать технологию VMware Fault Tolerance (в целом работает, но не поддерживается).

Так что способ защиты vCenter остался, по-сути, только один. Но и ничего страшного - не такая это суперкритичная часть инфраструктуры. Разворачивайте его в виртуальной машине, бэкапьте, включайте в кластер HA, да и все.

Поддержка VMware vCenter Server Heartbeat продлится до сентября 2018 года, поэтому пока можно не волноваться. Об остальном можно прочитать в FAQ на странице продукта.

На днях компания Amazon выпустила интересное решение - AWS Management Portal for vCenter, содержащее в себе бесплатный плагин к vCenter (AWS Connector for vCenter), который позволяет управлять виртуальными машинами, находящимися в облаке EC2 прямо из консоли vCenter. Многие после этого задумались - это шаг навстречу или против VMware?

Судя по функции "Migrate VMware VMs to Amazon EC2" на последнем скриншоте - это шаг против. Но на самом деле, все равно. Штука полезная, так как довольно большой процент компаний использует одновременно частное облако VMware и виртуальные машины из публичного облака Amazon.

Плагин поставляется в виде виртуального модуля (Virtual Appliance) в формате *.ova и предоставляет следующие возможности:

• Self-Service AWS Portal within vCenter - возможность развертывания новых инстансов и управления ими прямо из консоли vCenter. Портал позволяет определять, какие виртуальные сети, ресурсы и шаблоны будут использоваться для создания ВМ. Поддерживаются также возможности Single Sign-On (SSO) и Role-Based Access Controls (RBAC) для инфраструктуры AWS. Кроме того, поддерживаются возможности по генерации отчетов по биллингу на основе тэгов, назначенных системам.
• Migrate VMware VMs to Amazon EC2 - возможность миграции виртуальных машин в облако Amazon. Просто в контекстном меню виртуальной машины выбираем пункт "Migrate to EC2", после чего указываем регион, тип инстанса, подсеть - и виртуальная машина поехала с ESXi в AWS. После миграции ей можно продолжить управлять все с помощью того же Management Portal.
• Leverage vCenter Experience While Getting Started with AWS - а вот этот пункт нам явно говорит о том, что Amazon не настроена партнерствовать. С помощью портала самообслуживания пользователи VMware, не знакомые с IaaS-инфраструктурой AWS могут создать новый инстанс, указав все его необходимые параметры, не обращаясь к облаку Amazon. Ну а потом можно и вовсе переехать на AWS.
• Reach New Geographies from vCenter - как одно из преимуществ облака Amazon преподносится то, что теперь инстансы можно размещать на разных континентах, что положительно скажется на качестве обслуживания пользователей.

Полезные ресурсы по AWS Management Portal for vCenter:

• User Guide
• Setup AWS Management Portal for vCenter
• AWS Management Portal for vCenter License Agreement
• Основная страница AWS Management Portal
• Обзорная статья

Скачать AWS Management Portal for vCenter можно про этой ссылке.

Кроме того, на днях также вышел Magic Quadrant от компании Gartner в сфере облачных вычислений и инфраструктуры как услуги (Infrastructure-as-a-Service) - Magic Quadrant for Cloud Infrastructure as a Service (IaaS). Компания Amazon там впереди всех настолько, насколько примерно VMware впереди всех в области серверной виртуализации в частных облаках:

Вспомним квадрант по серверной виртуализации в 2013 году (кстати, еще посмотрим, как он будет выглядеть в этом году):

У VMware, как вы помните, также есть свое публичное облако - VMware vCHS, а вот у Amazon средств для создания онпремизной инфраструктуры нет. Посмотрим, сможет ли VMware подтянуться к Амазону.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.

"Интегрирован" - означает, что любая нештатная ситуация, случившаяся с хостами ESXi должна быть обработана на стороне обоих механизмов, а также решение этой проблемы находится в компетенции поддержки VMware. И правда - ведь отказавший хост ESXi нарушает целостность обоих кластеров, поскольку предоставляет и ресурсы хранилищ, и вычислительные ресурсы.

При этом, например, в случае каких-нибудь сбоев в сети может произойти "разделение" кластеров на сегменты, что может повлечь неоднозначность в их поведении, поскольку они используют разные сети для поддержания кластера (хождения хартбитов).

Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:

Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:

Вот тут и возникает 3 основных вопроса:

• Какие хранилища нужно использовать в качестве datastore heartbeat?
• Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
• Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?

Ну а в статье на блогах VMware даются вот такие ответы:

1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.

2. По поводу isolation address есть следующие рекомендации:

• При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
• Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
• Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.

3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:

А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:

Логика тут в принципе понятна, но в каждой конкретной ситуации может быть масса тонкостей касательно различных сценариев разделения и сбоев в сети, так что эти таблички лишь определяют направление мысли, а не дают готового рецепта.

В этом коротеньком посте приведем список горячих клавиш, которые помогут вам управляться с vSphere Web Client.

• Ctrl + Alt + 1 = Перейти в представление Home
• Ctrl + Alt + 2 = Перейти в представление vCenter Home
• Ctrl + Alt + 3 = Перейти в представление Hosts & Clusters
• Ctrl + Alt + 4 = Перейти в представление VM & Templates
• Ctrl + Alt + 5 = Перейти в представление Datastores
• Ctrl +Alt + 6 = Перейти в представление Networks
• Ctrl + Alt + S = Поместить фокус в поле поиска (Search)

Мы довольно часто пишем о "вложенной" виртуализации, которая позволяет запускать гипервизор VMware ESXi в виртуальной машине поверх ESXi, установленного уже на физическом сервере (nested virtualization). Для таких виртуальных ESXi есть даже свои VMware Tools. Однако, отметим сразу, что такое использование виртуализации официально не поддерживается со стороны VMware (в производственной среде), хотя и активно применяется в частном порядке ее сотрудниками, партнерами и заказчиками.

Так вот у многих администраторов есть закономерный вопрос - а надо ли лицензировать такие виртуальные ESXi? Ведь они все равно, кроме как для тестов, ни на что не годятся. Ответ прост - лицензировать надо. Об этом прямо написано в KB 2009916:

• VMware ESXi/ESX running in VMware Workstation or VMware Fusion
• VMware ESXi/ESX running in VMware ESXi/ESX
• VMware ESXi/ESX running in other third-party hypervisor solutions

Для тех, кто не хочет платить или хочет заплатить поменьше, есть 2 варианта:

• Постоянно переустанавливать ESXi в составе vSphere с триалом на 60 дней.
• Использовать бесплатный vSphere Hypervisor (он же Free ESXi) - но без vCenter.
• Использовать виртуальный ESXi, но с одним vCPU и, как следствие, платить только за одну лицензию. При этом можно поставить несколько виртуальных ядер на этот vCPU, и производительность будет почти та же, что и при нескольких процессорах. Как раз для этих целей VMware и был придуман параметр cpuid.coresPerSocket.

Одна из самых популярных статей на VM Guru - это статья про типы дисков виртуальных машин на платформе VMware vSphere. Там рассказано про все имеющиеся виды виртуальных дисков, среди которых можно выделить три основных:

• Lazy zeroed thick disks - все пространство диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Но при первом обращении ВМ к этому блоку он обнуляется.
• Eager zeroed thick disks - все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки.
• Thin disks ("тонкие диски") - эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски экономят пространство на массиве, так как не забивают его нулями и не требуют аллокации заданного объема.

Между администраторами VMware vSphere очень часто возникает дискуссия: диски какого типа нужно создавать, особенно если дело касается высоких нагрузок ВМ на дисковую подсистему? Сейчас это становится актуальным и для флэш-массивов, которые начинают появляться в организациях различного масштаба и предназначены как раз для высоких нагрузок ВМ на диски.

Специально для таких пользователей компания VMware провела тесты для последовательных и случайных операций при работе с виртуальными дисками различного типа, используя для этого дисковые массивы с SSD-накопителями.

Результаты оказались интересны - диски типа Thin и Lazy zeroed серьезно уступают в производительности дискам Eager zeroed, когда дело касается нагрузок случайного типа.

Использованная тестовая конфигурация:

• Сервер Dell R910 с 40 ядрами и 256 ГБ оперативной памяти.
• Дисковый массив Pure FA-420 FlashArray с двумя полками, на которых 44 флэш-диска по 238 ГБ каждый (суммарно 8.2 ТБ полезной емкости).
• Виртуальная машина Windows 2008 R2 Virtual Machine следующей конфигурации: 4 vCPU, 8 GB RAM, 40 GB OS/Boot Disk, 500 GB Data Disk.
• Инициатор SW iSCSI для карточки 10 Gb.

Таблица результатов тестов, сделанных с помощью IOMETER для различных размеров блоков:

Из таблицы видно, что все диски на последовательных нагрузках показывают примерно одинаковый результат, а вот на Random-нагрузках уже совершенно другая картина. Все это более наглядно можно увидеть графиков, где диски Thin и Lazy zeroed существенно проседают по производительности:

Вывод - не все йогурты одинаково полезны. Для высокопроизводительных нагрузок желательно использовать диски типа Eager zeroed - хуже точно не будет. Единственный их минус - требуется существенное время на их создание, поскольку происходит обнуление блоков. Но если ваш дисковый массив поддерживает примитивы VAAI, то много времени не понадобится: например, в том же тесте диск Eager zeroed размером 500 ГБ создался менее чем за одну минуту.

Мы достаточно часто пишем о средстве для создания отказоустойчивых кластеров VMware Virtual SAN (статьи можно найти по тэгу VSAN). Не так давно мы писали про документ, который позволяет правильно выбрать серверное оборудование для создания кластеров VSAN, а в этой заметке на основе информации от Дункана Эппинга, мы расскажем о выборе дисков для Virtual SAN.

Как известно, на одном хосте VMware ESXi, являющимся узлом VSAN, может быть до пяти дисковых групп (Disk Groups), каждая из которых содержит один SSD-диск и от 1 до 7 HDD-дисков:

Возникает резонный вопрос, что лучше - иметь одну дисковую группу большой емкости или несколько дисковых групп емкостью поменьше. Например, у вас такие требования к кластеру VSAN:

• Всего нужно емкости : 20 ТБ
• Всего емкости флэш-накопителей (10% по best practices): 2 ТБ
• Всего хостов ESXi: 5

В этом случае на каждом хосте можно использовать одну из двух альтернативных конфигураций:

• 2 x 2 ТБ SAS-диска и 1 x 400 ГБ флэш-диск (одна дисковая группа)
• 4 x 1 ТБ SAS-диска и 2 x 200 ГБ флэш-диска (две дисковых группы)

Тут получается три аспекта, на которые влияет выбор конфигурации:

1. SSD-диск+HDD-диски дисковой группы являются единой точкой отказа (fault domain), так как отказ единственного SSD-накопителя приведет к отказу дисковой группы в целом. В случае отказа флэш-накопителя данные вы, конечно, не потеряете, но понадобится некоторое время, чтобы восстановить избыточную конфигурацию. Так что чем больше групп, тем лучше.
2. С точки зрения производительности - также лучше иметь две дисковых группы. Как вы знаете SSD-диск используется для кэширования данных, а один диск большей емкости, хоть и выжимает больше IOPS, но не намного. То есть, в первом случае, например, вы будете получать на кэше 36 000 IOPS, а во втором 2 x 32 000 IOPS. Аналогично, больше иопсов будут выжимать и HDD-диски. Очевидно, второй случай с точки зрения производительности - выгоднее.
3. Затраты - здесь надо балансировать между оптимальной емкостью SSD-накопителей и HDD-дисков. Диски большой емкости, начиная с какой-то точки, стоят намного дороже. Тут второй вариант тоже в плюсе.

Итого - несколько дисковых групп на хосте небольшой емкости лучше одной гигантской дисковой группы.